Metadata is information describing a computer program that is stored either in a common language runtime portable executable (PE) or in memory. When program code, type information and data is compiled into a PE file (i.e., an assembly), metadata is inserted into one portion of the file, whilst code is converted into an intermediate language (IL) and inserted into another portion of the file. Every type, all type members—fields, methods, properties and events, are defined and referenced in a module or assembly is described within metadata. For instance, assembly metadata includes information to describe assembly identity (name, version, culture, public key, etc.), types (name, visibility, base class), exported types, descriptive elements that modify types and members, referenced assemblies, security permissions needed to run, interfaces implemented, and so on.
A metadata consumer (e.g., a browser, linker, compiler, runtime, integrated development environment (IDE), etc.) performs its respective functions by loading metadata into memory to discover information about the consumer code's types, members, inheritance, etc. Different consumers may use different metadata or share the same metadata for various purposes. Anyone building such a consumer must read and incorporate details of metadata layout, the structure of which is fixed/“hardwired” and enforced with a standardized schema, and semantics or meaning of the metadata to use the metadata. For instance, versions 1 and 1.1 of the Common Language Runtime (CLR) hard-wire metadata content and structure stored in assemblies—that's to say, each assembly uses the same schema as documented in the well known ECMA-335-II document. Anyone building software that attempts to understand an assembly has no choice but to read and digest the details of layout and meaning defined in that document. Put another way, the metadata is not self-describing.
Entities such as computer programmers, business development, and so on, often strive to create new useful products and to improve existing products, for instance, by adding features to computer languages, the CLR, and/or other software tools, to add a new table to change capabilities of a metadata consumer, etc. Such product development/enhancement typically requires changes, or extensions to the kinds of metadata that are stored in existing assemblies. (Use of “custom attributes” and/or “custom modifiers” associated with already standardized data is not considered a metadata extension, but rather a “decoration” of already standardized data). However, since the layout of consumer metadata is hardwired with a fixed representation, such extensions will be incompatible and almost guaranteed breaking to most existing metadata consumers (i.e., applications that attempt to import the extended metadata used to support the new feature(s)). Execution of an unmodified consumer of the metadata may result in undesirable consequences such as application and/or system crashes or lock-ups, data corruption, etc. An unmodified consumer is a metadata “importer” (e.g., a compiler/tool/common language interface (CLI), and/or the like) that has not been rewritten and recompiled to account for the newly added metadata.
For example, in view of a metadata extension, an unmodified metadata consumer might react as follows:    Not detect the presence of the extension (new information). This may or may not result in benign behavior. For instance, a class browser that does not report that a particular method has a constant for a first parameter (i.e., as indicated by extended metadata) may not result in a browser crash or lockup. However, another CLI that cannot parse new metadata indicating that a particular method is aliased (redirected) to another method may result in substantially (or, indeed, catastrophic) undesirable runtime behavior.    Detect presence of the extension and gracefully report an invalid assembly.    Detect presence of the extension and crash (e.g., crash at the point of detection, or sometime later) due to poor validation within the importer.    Etc.
To avoid undesirable runtime failures in view of newly added metadata extension(s), each and every importer of the extension typically needs to be rewritten and recompiled to successfully parse the extension. Requiring computer programmers to rewrite and recompile metadata consumer(s) can be substantially time consuming, error prone, and labor intensive. To make matters worse, incompatible metadata consumer-breaking behavior may occur with respect to every new feature added to metadata. This problem becomes even larger when the metadata extension is to be shared across multiple different types of metadata consumers.
Accordingly, conventional systems and techniques make it substantially difficult to extend metadata to support new metadata consumer functionality without engaging in potentially time consuming, labor intensive, error-prone, and costly efforts to rewrite and recompile each and every metadata consumer that may use the modified metadata.